The present invention generally relates to industrial control systems, and more particularly to systems and methods that provide secure and firewall restricted Web-based access to control devices and components residing on a non-IP network within an industrial environment.
A typical computer network comprises a plurality of interconnected microprocessor-based devices with specialized (e.g., network) software and/or hardware that facilitates interaction between at least two devices on the network. Such interaction can provide for a fast, efficient and cost-effective means to monitor, control and/or exchange information amongst networked devices such as printers, plotters, workstations, copiers, etc.
Communication networks that link computing devices (e.g., servers, workstations, etc.) and other devices (e.g., lights, sprinkler systems, printer, plotters, etc.) together are typically categorized and differentiated through characteristics such as size and user base, architecture, and topology. For example, a network can be referred to as a Local Area Network (LAN) or a Wide Area Network (WAN), dependent on the network size. A LAN is typically associated with a relatively small geographic area such as a department, a building or a group of buildings, and employed to connect local workstations, personal computers, printers, copiers, scanners, etc. while a WAN typically is associated with networks that span larger geographical areas, and can include one or more smaller networks, such as one or more LANs. For example, a WAN can be employed to couple computers and/or LANs that reside on opposite ends of a country and/or on opposite sides of the world. The most popular WAN today is the Internet.
Various types of communication protocols have been developed to facilitate communication between remotely located network devices. For instance, one common type of network based protocol is referred to as an internet protocol (IP). In an IP network, a source device generates data packets that include information (e.g., data to be delivered to a destination device, requests for certain data from a destination device, etc.) to be transmitted to a destination device, a source identifier that identifies the source of the data packet and a destination address associated with the destination device. Here, the source identifier and destination address fields in an IP packet are located in “framing” sections of the packet either before or after a data field. Hereinafter, unless indicated otherwise, the framing fields of an IP packet will be referred to as IP packet frames. Once an IP data packet is transmitted, network routers and hubs that receive the packet analyze the packet frames to identify the destination address, attempt to identify the most efficient way to deliver the packet to the destination device and then retransmit the packet to another network device until the packet arrives at the destination device. Here, the destination device is programmed to receive the packet, decode the packet information and typically perform some process associated with the decoded information. For instance, a first packet may be routed to a printer to print a document, a second packet may be routed to a light switch to turn on a light, a third packet may be routed to a stock brokerage server to request information about a client's account, etc. Examples of IP based networks include EtherNet/IP, EtherNet 10Base-T, 100Base-T (Fast EtherNet) and 1000Base-T (Gibabit EtherNet).
While IP networks have proven extremely useful in many applications, IP networks have several shortcomings that render the networks impractical for time sensitive applications. For instance, because IP network routing paths vary, the time required to transmit IP messages to destination devices varies appreciably. Similarly, excessive traffic over an IP network slows IP transmission rates so that packet delivery time is dependent on unpredictable factors. In addition, in at least some cases, servers that communicate via IP, enforce timeout rules wherein, if a packet has been transmitted from a source but the transmission period exceeds some threshold time period (e.g., due to network traffic), the message is discarded and has to be subsequently resent.
Thus, while IP networks are advantageous in applications where transmission time is not critical (e.g., a printing application, a request for information from a broker, sending an e-mail, etc.), IP networks have not been suitable in cases where information has to be transmitted almost instantaneously and at least within predictable time periods. Industrial controls is one application where unpredictable routing delays have rendered IP networks impractical in the past.
An exemplary industrial manufacturing line may include several machining stations (and associated devices and subassemblies—e.g., switches, sensors, motor starters, pushbuttons, I/O blocks, welders, robots, drives, bar code readers, etc.) along a transfer line, several programmable logic controllers (PLCs), one or more human-machine interfaces (HMIs) and a network that links the other components together where the PLCs are programmed to read inputs from stations and transfer line devices and provide outputs to the devices as a function of control programs stored in the PLCs. In many cases device and subassembly control at each station and between stations or between stations and the transfer line may have to be precisely synchronized in order for the line devices and assemblies to function properly and safely (e.g., a first robot arm could be damaged if the arm is driven into a line station prior to a second robot arm being removed from the station). Where device and subassembly timing is important, unpredictable IP network delays and periodic failures cannot be tolerated.
Early industrial control systems employed discrete signal wires between sensors and controllers and between controllers and actuators to ensure fast and predictable response times where control was modified by direct connection to the controller.
More recently, small groups of signal sensors and actuators have been tied to remote I/O concentrators where the concentrators have been networked to the controllers. In some cases, devices have been designed where network interfaces are embedded in the devices themselves. Exemplary devices of this type include DeviceNet and ControlNet devices that have been developed by Rockwell Automation. DeviceNet, ControlNet and other types of devices that include embedded network interfaces will be referred to generally hereinafter as non-IP devices.
In addition to developing non-IP devices suitable for use in industrial environments, industrial networking protocols have been developed for use with the non-IP devices where the industrial protocols use data packet formats that specify specific network paths from source devices to destination devices and therefore can transmit data in predictable time periods. One exemplary type of industrial protocol for use with DeviceNet and ControlNet devices is referred to as the control and information protocol or the common industrial protocol (CIP). Another exemplary non-IP protocol suitable for use with some types of industrial devices is referred to as Data Highway Plus. Other non-IP protocols are contemplated. Where an Ethernet links an HMI to a destination ControlNet or DeviceNet device through three additional ControlNet or DeviceNet devices (hereinafter “transmission path devices”) arranged in a series, a CIP data packet will specify the packet source, information to be delivered to a destination device, the destination device address and a specific path through the networked devices from the source to the destination device.
Here, the path specification includes the addresses of each of the three intervening transmission path devices and the order in which the devices are linked. For instance, in the present example that includes a three device path and a destination device, the path data includes first, second and third transmission path device addresses and identifies the destination device address separately. During transmission of the CIP packet, the source routes the packet to the address of the first device in the path, the first device identifies the second path device address in the packet and routes the packet to the second address. The second path device identifies the third path device address in the packet and routes the packet to the third device address and the third device identifies the destination device address and routes the packet to the destination device to complete delivery of the packet. The specified path method used in CIP communication, unlike IP, results in a deterministic communication protocol that is suited for use in industrial environments.
Even more recently, for various reasons, industry members have adapted the specialized industrial network devices such as ControlNet and DeviceNet devices for use with open standards like Ethernet. For instance, in the case of CIP, CIP packets have been encapsulated within Ethernet or IP packet frames for routing via Ethernet. The result of this adaptation is that programming interfaces and sometimes controller to device interfaces are now communicating via Ethernet IP.
One advantage of non-IP devices like DeviceNet, ControlNet, etc., is that the devices can be configured into a non-IP network that is less expensive than a typical IP network as the need for network switches is eliminated. In addition, DeviceNet, ControlNet and other similar network configurations have intrinsic safety features that are not provided by an IP network. For this reason, in many cases, it is most advantageous to configure hybrid networks including some IP network devices and some non-IP network devices specially designed for industrial applications (e.g., DeviceNet, ControlNet devices).
While industrial control has historically been limited to confined and secure spaces such as within a manufacturing facility, in cases where pure Ethernet or hybrid networks (e.g., including a combination of IP and non-IP (e.g., DeviceNet, ControlNet) network devices) are used to route data between devices, the transparency of the Ethernet routing mechanism makes it possible to remotely monitor and control the networked industrial devices. The possibility for remote monitoring and control advantageously allows more flexible system layouts to be configured and reduces overall system costs where Ethernet infrastructure already exists to support other facility needs.
Unfortunately, one problem with pure Ethernet and hybrid networks is that the transparency of the Ethernet routing mechanism components presents security problems. For instance, where a LAN operated by a brokerage firm and including a server is linked to the Internet to allow customers to access account information, an unscrupulous computer hacker may attempt to access the LAN via an Internet connection to obtain information about one of the firm's client's accounts. As another instance, a hacker may maliciously attempt to access a banks software via the Internet to load a virus thereon that could scramble the bank's records and negatively affect the bank's business. As one other instance, a hacker may attempt to access a PLC and alter an industrial control program thereby causing damage to machine line components controlled by the PLC.
In addition to unscrupulous persons doing unsavory things via networked interfaces, in many cases even well intentioned network users may be able to unintentionally cause problems if they access networked devices. For instance, in the case of a maintenance engineer at a manufacturing facility, while the engineer may be trained to maintain a first type of manufacturing line, the engineer may not be trained to maintain a second type of manufacturing line. While in a facility including the first line, the engineer may have to be proximate the first line to perform diagnostics procedures, check operating values, etc., wherein the proximity requirement and visual feedback ensures that the engineer is accessing first line devices, not second line devices. Where remote access is facilitated via a pure Ethernet or hybrid system, proximity and visual feedback cannot be relied upon and the end result could be that the engineer unknowingly accesses second line devices rather than first line devices.
To ensure that unintended network access does not occur, information technology (IT) firewalls have been developed that, in effect, separate LANs and other sub-networks from the Internet and that operate as gatekeepers to keep unauthorized network users from accessing the sub-networks while still allowing access to authorized network users. To this end, a firewall generally intercepts attempts to access associated sub-networks and requires some type of proof of identity from a network user attempting to access the sub-networks prior to allowing access. Here, proof of identity may require entry of a user name and password or may be transparent to a network user (i.e., information transmitted from the user's interface device may indicate identity which is automatically identified by the firewall). Where a network user is not authorized to access a sub-network, the firewall restricts access and may perform some secondary security process such as creating a log, activating an alarm, etc.
While conventional IT firewalls work well in the context of pure IP communication, where a non-IP industrial protocol (e.g., CIP) is embedded within an IP or Ethernet frame, the embedded non-IP protocol could be used to perform unauthorized activities despite a properly functioning IT firewall. Here, when an IP or Ehternet packet including an embedded non-IP packet is received by a firewall, an IT firewall algorithm interrogates the IP packet frame information to determine if the packet should be passed through the firewall to a destination device identified in the IP packet frame. If, however, the destination device designated in the IP packet frame routes the packet further based on the non-IP routing information (e.g., addresses in an embedded CIP packet), the ultimate destination designated by the non-IP routing information is not protected. This “carry-through” routing is a concern whether the CIP packet is routed via Ethernet or some other native industrial network such as DeviceNet or ControlNet.
Thus, it would be advantageous to have a method and apparatus that allows devices linked to an IP network to access industrial and other devices linked to a non-IP network only when the accessing device or person using the accessing device has authority to access the destination device.